### Motivation and Context

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

This example shows how to achieve Semantic Caching with Filters.
`IPromptRenderFilter` is used to get rendered prompt and check in cache
if similar prompt was already answered. If there is a record in cache,
then previously cached answer will be returned to the user instead of
making a call to LLM. If there is no record in cache, a call to LLM will
be performed, and result will be cached together with rendered prompt.
`IFunctionInvocationFilter` is used to update cache with rendered prompt
and related LLM result.

Example includes in-memory, Redis and Azure Cosmos DB for MongoDB as
caching stores.
Common output which demonstrates that second execution is faster,
because the result is returned from cache:
```
First run: What's the tallest building in New York?
Elapsed Time: 00:00:03.828
Second run: What is the highest building in New York City?
Elapsed Time: 00:00:00.541
Result 1: The tallest building in New York is One World Trade Center, also known as Freedom Tower. It stands at 1,776 feet (541.3 meters) tall, including its spire.
Result 2: The tallest building in New York is One World Trade Center, also known as Freedom Tower. It stands at 1,776 feet (541.3 meters) tall, including its spire.
```

PR also contains a couple of fixes in Azure Cosmos DB for MongoDB
connector and a couple of additions in public API:
1. Added `FunctionResult? Result` property to `PromptRenderContext`. By
default it's `null`, because at prompt rendering stage there is no
available result yet. But it's possible to set result with some value -
in this case, prompt won't be sent to LLM. Instead, the result from
filter will be returned.
2. Added `string? RenderedPrompt` to `FunctionResult` type as
`Experimental`. By default it's `null`, and will be populated only when
`KernelFunctionFromPrompt` is executed. This property will provide a
couple of benefits:
- It's an additional way how to observe rendered prompt which was sent
to LLM during function invocation (today, it's possible to see it only
through filter or trace logging).
- Rendered prompt will be also available in function
invocation/automatic function invocation filters, which is required for
caching scenarios to store rendered prompt and LLM result together.

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄